These two variables seem to have been renamed? https://github.com/suitenumerique/docs/blob/d952815/src/backend/core/authentication/backends.py#L17-L28

I've fixed that in #1100

This should be clarified imo, it took me a while until I made the connection of currently root user & password credentials being the ones for

AWS_S3_ACCESS_KEY_ID=<s3 access key>
AWS_S3_SECRET_ACCESS_KEY=<s3 secret key>

Also maybe at least link to outside docs that explain how to set up a user? I imagine most (including me) are not familiar with how one usually sets up minio.

I'm currently trying to set that up, from my understanding I need to create a new user, https://min.io/docs/minio/linux/administration/identity-access-management/minio-user-management.html#id1 and then it sounds like I shouldn't use the user credentials directly but create an accesskey to put into the config? https://min.io/docs/minio/linux/reference/minio-mc-admin/mc-admin-accesskey-create.html#command-mc.admin.accesskey.create

Initially I added an example but I eventually dropped it. The intention here is more to provide a quick start example than a thorough process to go to production. I don't know if we want to go that deep in details, like creating a user with the correct permissions.

Docs requires some "complex" parts like an IDP and Object Storage, I think its important for those who want to self host those parts to read the upstream doc and understand by themselves all the implications.

In this context I think skipping user and policy creation and using the minio root user is good enough as an example.

In this case to create the user it would look like this:

1. Create policy for the bucket

cat > readwritedocs.json << EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::<your-bucket-name>/*"
            ]
        }
    ]
}
EOF

mc admin policy create myminio readwritedocs readwritedocs.json

2. Create user

mc admin user add myminio <username> <password>

4. Assign policy to user

mc admin policy attach myminio getonly --user=<your-user>

curious to have your thoughts on this @virgile-dev
should I add this part in the example ?

@lunika What do you think ?

A warning can be added on the OIDC and Minio part to make sure people read the related project documentation on how to go in production with these tools.

@unteem can you update accordingly please ?

@unteem Thanks for sharing the policy stuff!

And I guess the step after is to run mc admin accesskey create myalias <username> --access-key $AWS_S3_ACCESS_KEY_ID --secret-key $AWS_S3_SECRET_ACCESS_KEY, right? It's a bit difficult to figure out what Minio recommends for such as setup, e.g. you can also use the Minio root user & password for AWS_S3_ACCESS_KEY_ID and AWS_S3_SECRET_ACCESS_KEY and that works totally fine. I assume you can also use the user credentials we just created and that'll work. But given the variable naming in docs, I assume creating an accesskey is the recommended thing to do.

From my perspective, I'm setting this up as a small instance for at most 20 people that use it occasionally, so we don't need any fancy big setup with sharding, load balancing, etc. We also only have everything running on one server, so there's zero high-availability anyways.

So having in these docs here how to get to a usable and secure production (while ignoring all HA and extra things for larger instances) would be good imo.

Thanks again for working on this!

A warning can be added on the OIDC and Minio part to make sure people read the related project documentation on how to go in production with these tools.

Its already the case, there are 3 warnings in the beginning pointing to upstream documentation

> \[!CAUTION\]
> We provide those instructions as an example, it should not be run in production. For production environments, deploy MinIO [in a Multi-Node Multi-Drive (Distributed)](https://min.io/docs/minio/linux/operations/install-deploy-manage/deploy-minio-multi-node-multi-drive.html#minio-mnmd) topology

> \[!CAUTION\]
> We provide those instructions as an example, for production environments, you should follow the [official documentation](https://www.keycloak.org/documentation).

On minio I also point out that in prod, minio root user should not be used but a user with readwrite access

I'm not sure I can do more ?

@unteem Thanks for sharing the policy stuff!

And I guess the step after is to run mc admin accesskey create myalias <username> --access-key $AWS_S3_ACCESS_KEY_ID --secret-key $AWS_S3_SECRET_ACCESS_KEY, right? It's a bit difficult to figure out what Minio recommends for such as setup, e.g. you can also use the Minio root user & password for AWS_S3_ACCESS_KEY_ID and AWS_S3_SECRET_ACCESS_KEY and that works totally fine. I assume you can also use the user credentials we just created and that'll work. But given the variable naming in docs, I assume creating an accesskey is the recommended thing to do.

From my perspective, I'm setting this up as a small instance for at most 20 people that use it occasionally, so we don't need any fancy big setup with sharding, load balancing, etc. We also only have everything running on one server, so there's zero high-availability anyways.

So having in these docs here how to get to a usable and secure production (while ignoring all HA and extra things for larger instances) would be good imo.

Thanks again for working on this!

Yep if you want to use mc to do operations like creating a user, CRUD on buckets/objects etc. you will need to set an alias

I would recommend to use a specific user and not the root/admin even if in your setup it could be fine to use the admin user, its always better to have least privileges access. It makes even more sense if at one point you use this minio instance for other apps, better to have one "user" per app.

Am I mistaken or is Redis 5 EOL since a long time?

https://redis.io/docs/latest/operate/rs/installing-upgrading/product-lifecycle/

Given the new license of Redis it might also make sense to use Valkey by default instead?

good catch update to v8, I don't use redis in prod... :)
I think as an example it should be fine to leave redis, Valkey is indeed a good option.